QRZ! Ham Radio 9

home *** CD-ROM | disk | FTP | other *** search

/ QRZ! Ham Radio 9 / QRZ Ham Radio Callsign Database - Volume 9.iso / pc / files / p_misc / netconf.arc / UNIX.TXT < prev next >

Wrap

Text File | 1988-12-10 | 43.8 KB | 905 lines

Packet Radio and IP for the Unix[1] Operating System Clifford Neuman, N1DMM Wayne Yamamoto Department of Computer Science University of Washington Seattle, WA 98195 _A_B_S_T_R_A_C_T Many services are currently available on the ARPA Internet that would be of interest to amateur packet radio users. The ARPA Internet connects universities and other organizations around the world that speak TCP/IP. One advantage of running TCP/IP on packet radio is the ability to access these services, and to interconnect with other systems that are part of the internet. This paper describes the implementation of AX.25 as a link layer protocol for the Unix operating system and the use of this system as an IP gateway between our local amateur packet radio network and our department's ethernet at the University of Washington, which in turn provides access to the entire Internet. The potential role of such a system for amateur packet radio is discussed, and a mechanism to allow users that don't have the resources to run TCP/IP themselves to access such services is described. _1. _I_n_t_r_o_d_u_c_t_i_o_n In the past year, we have started to see wider accep- tance and use of layer three protocols in amateur packet radio. So far, most of this activity has been by people who are interested in advanc- _________________________ [1] UNIX is a trademark of AT&T ing the state of amateur packet radio. Many are people who deal with computer net- works outside of amateur radio, and would like to see similar facilities available within packet radio. Others have worked on mechanisms to solve some of the problems that amateur packet radio pro- duced, and their solutions have made a significant difference in the way people use packet radio in the parts December 6, 1988 of the country where their solutions are being tested. In order to get more use of layer three protocols by the users instead of the developers, there are two requirements that should be met. First, they need incen- tive. There should be some- thing that they can do using layer three protocols that they can't do using connection [2] mode. One incentive is the ability to access some of the services available on more established networks such as the ARPA Internet. Among these services are nameser- vice, file transfer, access to various databases, a more flexible system for electronic mail, and the ability to log into hosts on connected net- works. These services can be made available in two ways. Servers can exist directly on amateur packet radio hosts, or they can exist on other net- works with a gateway set up between the two networks. By connecting our local packet radio subnet to the internet, it is possible to access files on, and log into, computers at other internet sites (or at least, those where we have accounts). Secondly, we have to lower the cost of entry. Most packet users do not have IBM PCs, or computers of equivalent or greater power. Many are simply using termi- _________________________ [2] By ``connection'' mode we mean the existing connection mechanism pro- vided with TNCs when higher level protocols are not be- ing used. nals connected to their TNC. This is probably one of the reasons that NET/ROM is so popular. With a packet sta- tion and no special hardware, one is able to connect to a NET/ROM node, connect to another node through the net- work, and come out the other end. If we are to generate as much interest in layer three protocols such as TCP/IP, then we must make it easy for con- nection mode users to connect to, and use, a system that speaks IP. We can then point out the advantages they would have if their own system spoke IP directly. Among these advantages are the abilities to exchange mail and transfer files while simultaneously connected to one or more other systems. _2. _S_y_s_t_e_m _O_v_e_r_v_i_e_w We decided one way to approach the above problems would be to get a machine that is on our department's ether- net onto packet radio. We had a MicroVax-I[3] available for our use. The advantage of using such a machine is that it already supports many of the network services that are desirable in the packet radio community. Among these are electronic mail, remote login, file transfer, and name ser- vice. Although not presently running on the machine, there are other applications avail- able too, such as NNTP[4] which could be used as a bul- _________________________ [3] MicroVax is a trade- mark of Digital Equipment Corporation [4] Netnews Transfer Pro- tocol December 6, 1988 letin distribution mechanism. The existence of such a system gives users who have brought up TCP/IP something to connect to. The next step is to give people who aren't yet running TCP/IP something with which they can connect. To do this, we want to allow users to connect to our system in connection mode, and for them to be able to login to our system by this mechanism. The only other service we want to support in connection mode is mail. We would like to be able to exchange mail with PBBSs, which don't speak TCP/IP. _3. _R_o_l_e _i_n _a _p_a_c_k_e_t _n_e_t_w_o_r_k A machine such as the one I described above serves several functions in a packet radio network. It functions as a server for various net- work services. It is useful as a ``home'' machine for those users who do not have computers of their own. It also can serve as a gateway between multiple packet sub- nets, and perhaps even non- amateur networks. I have already described its use as a server. In this section I describe its use in some of these other functions. _3._1. _H_o_m_e _m_a_c_h_i_n_e_s For those users who don't have IP running, our machine can serve as a home machine. Users can connect to it by using connection mode. The system can support multiple connections of this type simultaneously. When a user is connected to our system, he can use the various services available to IP hosts. He also will be allocated a lim- ited amount of disk space, and will be able to retrieve files in which he is interested. The mail interface the user will be able to use presents a better interface than the cen- tral BBOARD mechanism which is currently in use. The user will be able to store messages indefinitely as long as he doesn't exceed his quota. _3._2. _L_e_v_e_l _2 _t_o _L_e_v_e_l _3 _G_a_t_e_- _w_a_y Since the user can con- nect to the system using con- nection mode, and since the system also speaks TCP, the system serves as a Level 2 to Level 3 gateway. Users will not have to give up connec- tivity with the old in order to begin using the new. _3._3. _I_P _G_a_t_e_w_a_y A machine such as the one described above is also a log- ical machine to use as an IP gateway, at least until such time as we have dedicated machines for such purposes. Gatewaying could be between multiple packet radio net- works, and even between non- radio networks such as the ARPA Internet. There are services avail- able on the ARPA Internet that are of interest to packet radio users. If there is a university in the area, it is likely that there may be an online database of upcoming events. There are also many mailing lists on the Internet that might be of interest to Amateurs. Connecting to non-amateur networks does bring up a December 6, 1988 number of issues, such as screening of messages in both directions. I discuss solu- tions to this problem later in this paper. _3._4. _N_E_T/_R_O_M NET/ROM fits in nicely with TCP/IP. IP can be run on top of NET/ROM. In such an arrangement, users on a LAN would speak IP on top of AX.25. Multiple LANs could then be linked together using NET/ROM. An IP gateway would exist on each local area net- work and would appear as a NET/ROM node to other NET/ROM stations. This arrangement is similar to the way that local area networks are linked by the ARPAnet. NET/ROM nodes correspond to the IMPs on net 10. _4. _R_e_l_a_t_e_d _W_o_r_k There has been a lot of work recently in the TCP/IP arena. Work has been done on Phil Karn's IBM-PC code, and it has been ported to other machines such as the Amiga, the Mac, and others. Steve Ward and Mike Chepponis have been working on additional features in order to give users greater incentive to upgrade to TCP/IP. Implementations of the TCP/IP code are needed for many more machines. Services such as the ones I have described also are needed for these machines. Not many peo- ple have access to a MicroVax as I did. It is a good machine to use in order to determine how network users react to such services. The more machines such services are available on, the more people will be able to set them up. _5. _I_m_p_l_e_m_e_n_t_a_t_i_o_n The Ultrix[5] kernel already had all the code necessary for Internet Proto- col. Because we did not modify the ``upper'' IP inter- face, layers riding on top of IP were able to use the packet radio medium without modifica- tion. Thus, TCP and UDP did not need to be modified and, similarly, applications run- ning on top of those protocols worked without modification. The IP code in the kernel did not require modification either. All we had to do was to find a way to take the IP packets generated by the ker- nel, encapsulate them in AX.25 packets, and send them off, using SLIP, to the KISS interface of the TNC. _5._1. _I_P _a_n_d _A_X._2_5 _a_n_d _t_h_e _g_a_t_e_w_a_y We chose to implement a pseudo-device driver for the packet radio interface. The driver supports the same calls as network device drivers do for other media such as ether- net. Our driver is a pseudo driver because there is not really any hardware on the bus for our packet radio con- troller. Instead, our con- troller is plugged into a dz[6] port, and the kernel must communicate with it through that port. _________________________ [5] Ultrix is a trademark of Digital Equipment Cor- poration [6] A controller for mul- tiple RS-232 ports December 6, 1988 Teaching the kernel to recognize the new interface was easy. There is a struc- ture called if_net that is associated with each inter- face. This structure contains pointers to the kernel pro- cedures, which are used to initialize the interface, send a packet, change parameters, and a few other operations. The next trick was to figure out how we could receive pack- ets. This was done by includ- ing a routine similar to the one that gets called in the ethernet driver when a packet arrives. The difference, though, is that our routine is called by the dz driver when- ever a character is received on the line to which the TNC is connected. As each character is read, we do some initial pro- cessing on the fly. In par- ticular, we unescape frame end characters that are embedded in the packet. When the final frame end is read, we check the header of the message, note the callsigns, note the layer three protocol type, and if it is IP, we add the encap- sulated IP packet to the queue of incoming IP packets to be dealt with by the existing upper layers. In order to implement the routines described above, we started with a few routines from Phil Karn's code for the IBM PC. These routines encap- sulated and decapsulated AX.25 packets. With a few modifica- tions these routines were made to work in the Ultrix kernel. The gateway functionality came for free. The way an IP gateway works is that when a packet is received, the system looks at its IP header to determine the destination address. If the destination address is not its own, it then decides which is the correct destination interface, and which system is the correct next hop. This is all done at the IP layer, and the same code that existed for gatewaying packets on ether- nets works for AX.25 subnets too. _5._2. _A_d_d_r_e_s_s _R_e_s_o_l_u_t_i_o_n _P_r_o_- _t_o_c_o_l The final task was to translate internet addresses into AX.25 addresses. This is done using ARP, the address resolution protocol, in the same manner that IP addresses are translated into ethernet addresses. But, AX.25 addresses look like amateur radio callsigns followed by a 4 bit system ID. To make matters worse, some entries may contain additional callsigns for digipeaters that are to repeat the packet. Thus, what is needed is a dif- ferent set of ARP routines for the packet radio interfaces. Phil Karn's IBM-PC code includes an ARP implementation that supports both AX.25 and ethernet addresses. Because we did not want to modify the code for our system that is used on the ethernet side, we decided not to take this code. ARP lookup occurs at layer two, and thus, gets called inside either the ethernet driver, or the AX.25 driver. The routing tables at the IP layer determine which driver is called. Since the ARP lookup occurs inside our code, we are able to call a separate routine that deals specifi- cally with AX.25 addresses. December 6, 1988 _5._3. _C_o_n_n_e_c_t_i_o_n _m_o_d_e As already discussed, we would like to support connec- tion mode on our gateway. Doing so would allow users who do not have the resources to run TCP/IP to be able to access IP network services. Further, users can give IP a try, and if they like it, then they might consider running it themselves. However, there is no reason, though, that con- nection mode should be sup- ported in the kernel as is IP. The way our implementa- tion is set up, it is easy to allow user level process deal with connection mode. We can tell the kernel that if a packet comes in, and its pro- tocol ID is not IP, that the packet should be placed on the input queue for the appropri- ate tty line. A user program can then read packets that the system isn't interested in from that line, and deal with the packets itself. By set- ting appropriate parameters for the kernel, additional filtering could be provided, though one would not want to do anything too complex in the kernel. The user level process that reads such packets would have to keep track of any con- nections and support connec- tion mode itself. Such a pro- gram could maintain multiple connections, and direct input to and output from pseudo ter- minals. This would allow con- nection mode users to log into the system. Such a program could accept connections to multiple SSIDs, thus allowing one SSID to be used for the transfer of mail with local non-IP bulletin boards. _5._4. _O_t_h_e_r _l_a_y_e_r _3 _p_r_o_t_o_c_o_l_s In addition to supporting connection mode, support could be provided in a similar manner for other layer 3 pro- tocols. I already mentioned how NET/ROM can be used to forward IP packets. One could conceivably support the rest of the NET/ROM interface in the same manner as connection mode is supported. Of course, NET/ROM users would not have the benefit of the additional services available using IP. _6. _U_n_r_e_s_o_l_v_e_d _i_s_s_u_e_s The ability to intercon- nect amateur packet radio net- works and non-amateur networks introduces a few problems which have not been completely resolved as of this time. In this section, I present those problems, and for some of them, I suggest some possible solutions. _6._1. _T_i_m_e_o_u_t_s One problem that comes up is the difference in bandwidth for the two networks. Hosts on the ethernet side expect fast response, and if they don't get a response quickly, they time out and retry their transmission. We have found that when connected to a sys- tem on our department's ether- net from a machine on the packet side of the gateway, the system on the ethernet side initially retransmits packets several times before a response makes it back. This results in wasted bandwidth on the radio side as the packet is needlessly retransmitted, and this in turn delays other packets. Fortunately for some implementations of TCP, once December 6, 1988 the connection has been esta- blished, the system on the ethernet side learns the correct timeout, and things settle down. _6._2. _I_n_t_e_r_n_e_t _r_o_u_t_i_n_g Routing is another prob- lem that arises if we want to allow connections to internet hosts beyond our department's ethernet. In order for a response to come back, all the gateways between the source and the destination must know the route to the appropriate packet radio subnet. Since a class `A' network is allocated for AMPRnet, and since most systems by default will main- tain a single route for a class `A' network, only one path exists for all of AMPRnet, whereas what is desired is different gateways for different subnets. It is conceivable that something like this could be handled using ICMP[7] redirects, but at this time, no mechanism is in place. _6._3. _A_c_c_e_s_s _C_o_n_t_r_o_l Another problem we face is access control. Since operation is on frequencies assigned to the amateur radio service, any communication must be initiated by licensed amateurs. One way we can solve this is to maintain a table of authorized addresses on the non-amateur side of the gateway. Associated with each of these addresses is a list of hosts on the amateur side of the gateway with which that _________________________ [7] Internet Control Mes- sage Protocol host can communicate. Ini- tially the table starts off empty. Whenever a packet is received on the amateur side destined for a non-amateur host, an entry is made in the table, enabling the non- amateur host to send packets in the other direction. After a certain period of time, these entries time out if packets have not been received from the amateur side of the gateway. This scheme can be aug- mented with a few new ICMP messages. One message can force an entry to be removed from the table of authorized non-amateur systems. This allows the amateur radio operator that initiated the link to exercise his control operator function to cut off the link if he detects inap- propriate use. Another mes- sage would allow one to add an authorized non-amateur host to the tables with an appropriate time to live. Both these mes- sage are allowed to come from either side of the gateway, but if they come from the non-amateur side, they must include a call sign and a password of for an authorized control operator for the gate- way. _7. _S_t_a_t_u_s The packet radio imple- mentation of IP works. We have successfully connected from an IBM PC with a packet radio controller to a machine on our department's ethernet using telnet.[8] The connec- _________________________ [8] One of several remote login protocols. December 6, 1988 tion was made using our MicroVax-I as a gateway. We also were able to telnet from the machine on the ethernet to the PC. In the Seattle area, we are using a duplex repeater as the base for our local area network. Our network extends from Seattle, south to Tacoma, west to a station on the other side of Puget sound, and east to the Cascades. We have not yet written the user program to support connection mode logins, but that is being considered. We also have not yet done any- thing towards using NET/ROM to interconnect our local area networks with others, but we would like to do that soon. _8. _C_o_n_c_l_u_s_i_o_n_s The Unix operating system provides a nice base upon which network services can be provided for the amateur packet radio community. At the same time, such a system can serve as a central node in the interconnection of local area networks running IP, and even those that don't run IP. By linking packet radio net- works with more established networks, additional services become available. Such ser- vices are available in the Seattle area. These services are necessary if we are to interest people in running TCP/IP. Further, interconnec- tion with non-IP packet radio users is necessary if we are to interest users who would like to try IP, but still want to maintain connectivity with those still using connection mode. _9. _A_c_k_n_o_w_l_e_d_g_m_e_n_t_s A number of people were helpful in getting our imple- mentation running and in dis- cussing some of the ideas presented in this paper. Among them are Bob Albrightson (N7AKR), Bob Donnell (KD7NM), Dennis Goodwin (KB7DZ), Mike Chepponis (K3MC), Steve Ward (W1GOH), and Ed Lazowska (KG7K). Thanks are also in order to Bob Hoffman (N3CVL) for typesetting this paper. _1_0. _B_i_b_l_i_o_g_r_a_p_h_y 1. Fox, Terry L.: AX.25 Ama- teur Packet-Radio Link- Layer Protocol. Version 2.0. American Radio Relay league, October 1984. 2. Karn, Phil: ``TCP/IP, A Proposal for Amateur Packet Radio Levels 3 and 4'', _F_o_u_r_t_h _A_R_R_L _C_o_m_p_u_t_e_r _N_e_t_w_o_r_k_i_n_g _C_o_n_f_e_r_e_n_c_e, San Francisco, 1985. 3. Leffler, S; Joy W.; Fabry R.; Karels M.: Networking Implementation Notes 4.3 BSD Edition. Computer Systems Research Group, University of California, Berkeley. June 1986. December 6, 1988